1.跨站脚本 xss
// xss是一种代码注入的方式
// 1.储存型
    // 攻击者将恶意代码提交到目标网站的数据库中
    // 用户打开目标网站时，网站服务端将恶意代码从数据库取出，拼接在 HTML 中返回给浏览器
    // 坛发帖、商品评论等
// 2.反射型
    // 攻击者构造出特殊的 URL，其中包含恶意代码。
    // 用户打开带有恶意代码的 URL 时，网站服务端将恶意代码从 URL 中取出，拼接在 HTML 中返回给浏览器。
    // 用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。
// 区别
// 反射型 XSS 跟存储型 XSS 的区别是：存储型 XSS 的恶意代码存在数据库里，反射型 XSS 的恶意代码存在 URL 里。
// 反射型 XSS 漏洞常见于通过 URL 传递参数的功能，如网站搜索、跳转等。
// 由于需要用户主动打开恶意的 URL 才能生效，攻击者往往会结合多种手段诱导用户点击。
// POST 的内容也可以触发反射型 XSS，只不过其触发条件比较苛刻（需要构造表单提交页面，并引导用户点击），所以非常少见。

// DOM 型 XSS
    // DOM 型 XSS 的攻击步骤：
    // 攻击者构造出特殊的 URL，其中包含恶意代码。
    // 用户打开带有恶意代码的 URL。
    // 用户浏览器接收到响应后解析执行，前端 JavaScript 取出 URL 中的恶意代码并执行。
    // 恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。
    // DOM 型 XSS 跟前两种 XSS 的区别：DOM 型 XSS 攻击中，取出和执行恶意代码由浏览器端完成，属于前端 JavaScript 自身的安全漏洞，而其他两种 XSS 都属于服务端的安全漏洞。
XSS 攻击有两大要素：
    // 攻击者提交恶意代码。
    // 浏览器执行恶意代码。
// 解决方法
// 存储型和反射型 XSS 都是在服务端取出恶意代码后，插入到响应 HTML 里的，攻击者刻意编写的“数据”被内嵌到“代码”中，被浏览器所执行。
// 服务端进行过滤 转译
// 改成纯前端渲染，把代码和数据分隔开。
// 做了 HTML 转义，并不等于高枕无忧。
    // 对于链接跳转，如 <a href="xxx" 或 location.href="xxx"，要检验其内容，禁止以 javascript: 开头的链接，和其他非法的 scheme。
// DOM 型 XSS 攻击，实际上就是网站前端 JavaScript 代码本身不够严谨，把不可信的数据当作代码执行了
// 如果用 Vue/React 技术栈，并且不使用 v-html/dangerouslySetInnerHTML 功能，就在前端 render 阶段避免 innerHTML、outerHTML 的 XSS 隐患。
// DOM 中的内联事件监听器，如 location、onclick、onerror、onload、onmouseover 等，<a> 标签的 href 属性，JavaScript 的 eval()、setTimeout()、setInterval() 等，都能把字符串作为代码运行。
    // 如果不可信的数据拼接到字符串中传递给这些 API，很容易产生安全隐患，请务必避免。
CSRF（Cross-site request forgery）跨站请求伪造：
// 攻击者诱导受害者进入第三方网站，在第三方网站中，向被攻击网站发送跨站请求。
    // 利用受害者在被攻击网站已经获取的注册凭证，绕过后台的用户验证，达到冒充用户对被攻击的网站执行某项操作的目的。
    // 伪造受害者的名义进行请求，从而达到自己的目的，只能使用cookie不能够获取到cookie

// 一个典型的CSRF攻击有着如下的流程：
// 受害者登录a.com，并保留了登录凭证（Cookie）
// 攻击者引诱受害者访问了b.com
// b.com向a.com发送了一个请求：a.com/act=xx浏览器会默认携带a.com的Cookie
// a.com接收到请求后，对请求进行验证，并确认是受害者的凭证，误以为是受害者自己发送的请求
// a.com以受害者的名义执行了act=xx
// 攻击完成，攻击者在受害者不知情的情况下，冒充受害者，让a.com执行了自己定义的操作
CSRF防护
// 上文中讲了CSRF的两个特点：
// CSRF（通常）发生在第三方域名。
// CSRF攻击者不能获取到Cookie等信息，只是使用。
// 针对这两点，我们可以专门制定防护策略，如下：

// 阻止不明外域的访问
    // 同源检测  Origin Header 和 Referer Header
    // Samesite Cookie 设置cookie属性 Samesite=Strict严格模式绝无例外，任何情况下都不能作为第三方的cookie 新打开一个标签页也不会有cookie信息 体验不好 
    // Samesite=Lax 假如这个请求是这种请求（改变了当前页面或者打开了新页面）且同时是个GET请求 则这个Cookie可以作为第三方Cookie
        // 但假如这个请求是从 a.com 发起的对 b.com 的异步请求，或者页面跳转是通过表单的 post 提交触发的 则也不会触发
        // 其他网站通过页面跳转过来的时候可以使用Cookie，可以保障外域连接打开页面时用户的登录状态
// 提交时要求附加本域才能获取的信息
    // CSRF Token     就是token作为一个参数在接口中传递
    // 双重Cookie验证  也是传递参数和cookie对比 一致就认为是安全的

网络劫持一般分为两种: 这个一般不在前端考虑的方向
// DNS劫持: (输入京东被强制跳转到淘宝这就属于dns劫持)
// DNS强制解析: 通过修改运营商的本地DNS记录，来引导用户流量到缓存服务器
// 302跳转的方式: 通过监控网络出口的流量，分析判断哪些内容是可以进行劫持处理的,再对劫持的内存发起302跳转的回复，引导用户获取内容
// HTTP劫持: (访问谷歌但是一直有贪玩蓝月的广告),由于http明文传输,运营商会修改你的http响应内容(即加广告)
    